\documentclass[12pt]{article}                                                     % Taille police et type de document
\usepackage{eurosym}
\usepackage{textcomp}                                                              %Package du symbole Euro
\usepackage[french]{babel}                                                        % Babel Francais pour l'euro
\usepackage[latin1]{inputenc}                                                     % gérer les accents
\usepackage[pdftex]{graphicx}                                                     % insertion images
\DeclareGraphicsExtensions{.jpg,.mps,.pdf,.png}                                   % Formats d’images
\usepackage{amsmath}                                                              % Les math c'est mal! (Madmass)
\usepackage[top=80pt, bottom=70pt, left=40pt, right=40pt]{geometry}               % Geometrie de la page
\usepackage{fancyhdr}                                                             % Package en-tete (Madmass)
\pagestyle{fancy}                                                                 % definition du style : FancyHDR (Madmass)
\fancyhf{}                                                                        % Remise a zero des entetes (Madmass)


\newenvironment{vcenterpage}
{\newpage\vspace*{\fill}}
{\vspace*{\fill}\par\pagebreak}
%%%% fin macro %%%%

%%%%%%%%%%%%%%%%%%%%%%%
\rhead{\texttt{MAPeG CORPORATION}}        %Droite Haut
\chead{}                                  %Centre Haut
\lhead{Projet: Boom$^{4}$}                %Gauche Haut
\rfoot{}                                  %Droite Bas
\cfoot{\thepage}                          %Centre Bas
\lfoot{}                                  %Gauche Bas


%Caracteristique du document (Auteurs etc...)
%%%%%%%%%%%%%%%%%%%%%%%
\title{\textbf{Projet: Boom $^{4}$\\ \includegraphics{boom4.PNG}}\\ 3$^{eme}$ Rapport aux actionnaires\\ }
\author{BERKANE Massy \\ BRUNETTI Pierre \\ CAMERA Guillaume \\ KOUYOUMDJIAN Alexandre}

%Debut Du document.
%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\maketitle
\newpage
\tableofcontents

\begin{center}
\includegraphics{scan3-1.jpg}
\end{center}

\newpage
\section{Préambule}
Chers actionnaires, nous voici maintenant rendus à notre 3eme rapport devant vous. Ce rendez-vous représentait pour l'équipe de développement 
un tournant important dans la vie du projet : comme vous l'avez remarqué lors de notre dernière présentation, l'objectif principal était de
sortir de nos prototypes aux allures de démo technologique et de s'acheminer vers un vrai jeu, présentant à la fois une cohérence mais aussi 
- et surtout - un interêt ludique!
\\
\\
\\
\\
\\
\\
\begin{center}
\includegraphics{logomapeg.png}
\end{center}
\newpage
\section{Introduction}
\subsection{Background}
Souvenez-vous : l'ONU, pour la sécurité de la planète, avait fait appel à nos compétences pour recréer la célèbre bataille ayant aboutie au renvoi de MegaZorg sur sa planète. Cependant, d'après des sources plutôt fiables, le vil aurait été aperçu en chair et en os (si chair et os il y a) sur NOTRE planète. Ce n'est que quelques semaines plus tard que nous nous rendîmes compte de la supercherie : l'ONU était déjà au courant. Cette mission n'était qu'un leurre, et Boom IV était l'appât. L'ONU nous avait donc implicitement donné le rôle de cible : nous étions les uniques personnes capables d'entrer en contact avec l'ignoble extraterrestre. 
Lorsque nous apprîmes que la bête se trouvait sur Terre, notre sang ne fît qu'un tour : nous diffusâmes aussitôt le lien vers notre site sur le web. Ca ne manqua pas : MegaZorg mordît à l'hameçon. Trois jours plus tard, un mail de provenance inconnue déboula dans notre boite mail : il nous donnait rendez-vous dans un Kebab, dont nous tairons le nom pour des raisons d'intégrité morale, très tôt, c'est-à-dire vers 13h. Nous organisâmes donc un commando sur-armé, un plan d'attaque en béton armé, puisque nous n'avons pû obtenir celle de l'ONU (l'armée).
Deux heures plus tard, nous revînmes avec un MegaZorg menotté, cagoulé, déshonoré, tant il fut facile de le capturer.
Nous l'avons donc remis à l'ONU, et nous avons été finalement récompensés : nous disposons actuellement des moyens nécessaires pour finaliser Boom IV, le jeu qui ébranlera même Christophe Boullay (réputé pour être l'incarnation de l'inébranlabilité sur notre planète).
L'ONU nous a également permis d'amener MegaZorg à cette troisième soutenance, histoire de se fou... moquer un peu de lui, et pour prouver que nous ne sommes pas des incapables à la MAPeG Corporation.   

\newpage
\subsection{Planning \& Avancées}
Voici les résultats de notre développement à ce jour : conformément à nos prévisions pour cette troisième soutenance, nous
avons accompli les tâches suivantes :
\begin{center}
\begin{tabular}{| c | c | c | c | c |}
\hline  & Alexandre & Guillaume & Massy & Pierre \hspace{0.5cm}\\
\hline
 Moteur 3D &  & $\Theta$ & $\Theta$ & \\
 \hline
 Moteur Physique & $\Theta$ & & & $\Theta$ \\
 \hline
 IA & & & & $\Theta$ \\
 \hline
 Site Web & & $\oplus$ & & $\oplus$ \\
 \hline
 Son & & & & $\oplus$ \\
 \hline
 Gameplay  & $\Theta$ & $\Theta$ & $\Theta$ & $\Theta$ \\
 \hline
\end{tabular}
\end{center}

Légende :\\
$+$ : ébauche\\
$\Theta$ : avancé\\
$\oplus$ : terminé \\

Tout va bien, la MAPeG a atteint les objectifs qu'elle s'était fixés pour la troisième soutenance. Malgrès la chaleur tombée sur nos locaux sous-climatisés. Nous avons abattu la charge de travail qui nous incombait et le projet se porte bien.

À présent chacun des départements de la MAPeG va vous présenter le travail accompli par son staff ainsi que les perspectives concernant la suite du projet.
\newpage
\begin{vcenterpage}
\includegraphics{physics_dep.PNG}
\end{vcenterpage}
\newpage
\section{Département Physique}
\subsection{Introduction}
Haaaa, quel vide ! Oui, un vaisseau qui bouge bien, mais qui traverse les murs ! Et puis en plus il est tout seul, c'est même pas rigolo.
Donc, deux choses à ajouter : des collisions, et des ennemis. Aussitôt dit, aussitôt fait ! Enfin non hein, le aussitôt à pris un peu de temps quand même ...
\subsection{Problématique}
Comme vous avez pu le remarquer au cours de notre démonstration, 80 ennemis sont affichés à l'intérieur de la skybox. Il a fallut de 1, ne pas les faire sortir de cette skybox, et de deux, les faire bouger. Ils nous tireront dessus à la dernière soutenance, il leur faut un peu de temps pour se mettre en route ...
Brunetoli a donc codé une procédure de pseudo intelligence artificielle, mais les déplacements ne sont pas vraiment fluides : on dirait plus un androïde atteint d'Alzeihmer que de véritables ennemis oppérationnels. Kouyou est donc arrivé à la rescousse, et a bossé - oui, en vrai !! - sur des déplacements dignes de ce nom. Et la lumière fut. Des ennemis qui bougent, ouais ! Bon maintenant, faudrait qu'ils ne se cassent pas de la skybox. Kouyou vient au secours de la veuve et de l'orphelin, et nous pond une jolie procedure qui bloque les ennemis (et le vaisseau par la même occasion, parce que c'est quand même mieux de ne pas sortir de l'espace).
Des ennemis qui bougent, mais maintenant faut leur tirer dessus, les bougres !
Et c'est ainsi que trois de nos compères, à savoir Massy, Kouyou et Guillaume, se défoncèrent le crâne. Après de longues heures passées à martyriser leur clavier, il en résultat, à force de travail et d'acharnement, des tirs, des vrais.
Kouyou coda une fonction pour savoir si oui ou non, le laser a atteint un ennemi, et Guillaume s'occupa de le retirer de sa liste.
Nous avons egalement rajouté une variable score, qui comptabilise le nombre d'ennemis abattus.
Pour finir, au lieu de traverser les ennemis, c'etait quand même plus sympa de les faire exploser : mais en contrepartie, pas de score pour ceux-là, mais ils vous font perdre de la vie. Ha ben oui on peut pas tout avoir ...
Kouyou a même tenté une fonction de collision avec notre map, mais cela s'est averé plus difficile que prévu : la map est scalée, puis translatée, bref, on ne peut obtenir les coordonnées exactes de chaque point de la map par rapport à celles du vaisseau. Cette fonction semblait pourtant marcher partiellement, puisqu'elle bloquait le vaisseau au niveau le plus haut de notre map.

Prochain objectif, des ennemis qui nous tirent dessus, histoire de mettre un peu de piment dans ce jeu déjà bourré d'action et de rebondissements.

\newpage

\begin{vcenterpage}
\includegraphics{graphics_dep.PNG}
\end{vcenterpage}
\newpage
\section{Département Graphique}
\subsection{Introduction}
Les précedentes soutenances ayant fixé les bases solides d'un moteur graphique, notre dreamteam a concentré ses forces au services des autres départements.
Ainsi vous découvrirez que nous avons collaboré avec l'équipe chargée de la physique pour concrétiser les forces ennemies dans le jeu, ainsi que de ramener dans le jeu les armes qui permettront à notre héros de s'en debarrasser.

\subsection{Problématique}
Nous nous sommes vu confier la mission de créer et d'afficher des ennemis ainsi que des projectiles pour les détruire.\par
\subsection{Développement}
Les projectiles furent d'abord envisagés sous la forme d'un laser de type rectangulaire, mais cette solution n'était pas adaptée à notre système de direction du vaisseau. Nous nous sommes tournés vers deux formes ovoïdale qui tournoieraient en une sorte de centre de gravité - comme vous aurez sans doute pu le voir au cours de la démonstration - .
Ces deux formes sont texturées afin de donner l'illusion d'un laser.\\
Le Dessin des projectiles se fait à l'aide d'un \emph{vecteur3} qui représente la position du projectile. Ceci permettra a l'équipe Physique de déplacer facilement ces projectiles. \par
Les ennemis sont chargés sous forme de modèles, stocké dans notre table de hash qui contient tout nos modèles. De même leur tracé se fait grâce a un vecteur3 qui représente la position.\\
Toutes ces opérations (Ajout/suppression dans la table, Dessin etc\ldots ) se font grâce a nos fonctions précodées.\\ 

\newpage
\begin{vcenterpage}
\includegraphics{sound_dep.PNG}
\end{vcenterpage}
\newpage

\section{Département Média}
\begin{quotation}
Most rock journalism is people who can't write, interviewing people who can't talk, for people who can't read.  
\end{quotation}
\subsection{Problématique}
Il n'y a pas eu d'énorme avancée au niveau des médias par rapport à la soutenance précedente : j'ai pu simplement, grâce à un BufferPlayflag de DirectX, jouer un son en boucle, pour l'ambiance. J'ai pu également, grâce à AudioVideoPlayback, jouer une vidéo, en fullscreen ou non. Je me frotte désormais à un souci, que faire en sortant de la lecture de cette vidéo ? Il existe un paramètre de la vidéo, video.Ending, qui est censé recevoir une procedure lui disant que faire une fois la vidéo finie, cependant je n'ai pas encore réussi à le manipuler. Ceci nous permettra, par la suite, d'inclure une vidéo d'introduction, ainsi que de revenir au menu une fois la vidéo de credits terminée; car pour l'instant, nous pouvons lire la vidéo, mais l'application se stoppe à la fin de la vidéo. J'approfondierai la lecture de vidéo pour la dernière soutenance, ceci n'étant qu'un détail "`esthétique"' . 
Quand au son du laser, il remplace le son de laser déjà en cours de lecture; idem pour le son de boost. C'est ce que nous avons trouvé le plus adapté aux tirs de laser.

\newpage

\begin{vcenterpage}
\includegraphics{conception_dep.jpg}
\end{vcenterpage}

\section{Le Département Conception} 
\subsection{Introduction}
Toujours dans cette optique de faire converger notre projet vers un VRAI jeu, la phase de configuation semblait être la prochaine étape, demander à l'utilisateur de modifier le code source n'étant pas une bonne solution (au cas les gens de SupInfo voudraient y jouer)\ldots \par
Nous nous sommes alors heurté a un Dilemme Cornélien : 
Ces réglages doivent--ils se faire ingame \emph{Old--School Style} ou via un utilitaire externe comme cela semble être la mode dans les jeux actuels ? \par 
La MAPeG n'étant pas du genre à faire des concessions, les deux possibilités seront donc offertes à nos utilisateurs (qu'on aime et qu'on chérit).\par
La pérennité des réglages devant être assurée la solution d'un fichier texte se presenta telle Dieu à Moïse. \par
Noud detaillerons ici les deux méthodes de manipulation du fichier de configuration avant de se pencher plus en profondeur sur sa structure. 

\subsection{Utilitaire Externe}
Cette méthode permet à l'utilisateur de sélectionner sa configuration avant de lancer le jeu et ainsi d'éviter un redémarrage forcé. \par 
Il se présente sous la forme d'une simple fenêtre permettant de sélectionner ses choix et de les valider.
L'ergonomie et l'esthétisme de ce module ont été les sujets de soins tout particuliers toujours dans le but de maximiser l'experience de l'utilisateur.

\subsection{Gestion Integrée}
Dans un souci de perfection, le menu ayant déjà été integré, il paraissait indispensable d'ajouter un sous--menu ``options'' au menu principal.
Ce sous--menu fonctionne exactement comme l'utilitaire externe, en utilisant le même fichier de configuration, sauf qu'il est ``in--game''.
Son implémentation s'est faîte de la même manière que l'intégralité du menu. Il est donc possible de régler la résolution, ainsi que l'antialiasing une fois l'application ouverte, comme dans un ``vrai'' jeu. Parce que le joueur passe avant tout, la MAPeG fait tout pour le satisfaire ; le réglage des options \emph{in--game} plaît à certains, et déplaît à d'autres : l'implémentation des deux utilitaires est donc la meilleure solution. 

\subsection{Structure}
Le fichier que nous allions utiliser devait répondre plusieurs critères : \par Tout d'abord il se devait d'être compréhensible par un être humain et modifiable aisément même avec un simple éditeur de texte, tout en restant pratique pour l'algorithme qui allait le parcourir.\par
Pour cette fois--ci le comité a decidé de laisser de côté les extension fantaisistes et d'en rester au conventionnel \emph{Config.ini}.
Celui--ci possédera une structure clairement définie tout en restant dynamique dans ses proportions.\par
Ainsi la première partie du fichier présente les crédits et quelques consignes simples pour celui qui veut modifier le fichier à la main. Cette partie 
peut être modifiée et allongée sans que le fonctionnement du programme s'en retrouve altéré. Vient alors la partie qui contient la configuration à proprement parler.
Les propriétés et leur valeur sont stockées sous le schéma suivant :\\
\begin{verbatim}
[Propriete]
Valeur
[Propriete]
Valeur
\end{verbatim}

\begin{center}
\includegraphics{robot.jpg}
\end{center}

\newpage

Après ce passage en revue, chacun des chefs de section va retracer ses semaines de labeur, relater ses impressions sur le projet. Cette
partie du rapport peut contenir quelques portions de code, les pauvres chefs de section n'ont plus que ça en tête en ce moment.

\begin{center}
\includegraphics{cahoboy.jpg}
\end{center}

\section{BERKANE Massy}
\subsection{Gestion de la Configuration}
Mon premier objectif pour cette soutenance était de présenter un système viable de gestion de la configuration. C'est tout naturellement que j'ai pensé à un système de fichier qui me
permettrait de stocker la configuration choisie par l'utilisateur. La méthode la plus simple aurait été de stocker à la barbare les valeurs pour les récupérer le plus rapidement possible.
Voici le premier prototype de fichier ini :
\begin{verbatim}
1024
768
No
Yes
0
\end{verbatim}
Cette version permettait une lecture rapide du fichier mais était une horreur à modifier et à comprendre à la main (en plus de devoir mémoriser à quoi correspondait chacune des lignes.
Cette solution fut d'ailleurs refusée lors de la réunion du bureau de la MAPeG.\par
Je me mis alors au travail pour créer un squelette \emph{User--Friendly}. C'est ainsi que le ``MAPEG Corp. ini FileSystem'' est né.
Nous allons détailler ici les spécifications de ce format :\\
\begin{verbatim}
###############################################################################
#####################               BOOM IV               #####################
#####################          Configuration File         #####################
#####################                                     #####################
#####################                 Note:               #####################
##############      - You can modifiy this file Manually but     ##############
##############         be sure to keep the capital Letters.      ##############
##############    If you're not confident use the configuration  ##############
##############                      Utility                      ##############
###############################################################################
\end{verbatim}
La première partie du fichier consiste en une petite introduction, celle--ci pourra être complétée au fur et à mesure des modifications apportées au système.
Vient ensuite la partie intéressante :
\begin{verbatim}
[Resolution]
1024x768
[FullScreen]
No
[AntiAliasing]
0
[WireFrame]
No
\end{verbatim}
La lecture du fichier est ainsi tres aisée permettant à n'importe quel utilisateur de le modifier intuitivement.
\subsection{Utilitaire de configuration}
Malgré l'intuitivité exacerbée de notre système de fichier, il fallait créer une interface graphique à la fois simple tout en restant extrêmement puissante pour le manipuler.
C'est ainsi que le \emph{Boom IV Configuration Utility} est né.\par
Fruit de la recherche de notre laboratoire en ergonomie cette interface couvrira TOUS les besoins de nos charmants utilisateurs.
Le programme testera ainsi l'existence ou non d'un fichier ini et le créera si besoin --- avec les options au minimum pour des soucis de compatibilité.
L'Utilisateur aura alors accès à un panel d'options de configuration et c'est lors de la fermeture que le nouveau fichier ini sera généré pour remplacer l'ancien.
\subsection{Utilisation de la configuration stockée}
Stocker la configuration est une bien belle chose mais s'en servir est le but principal de l'exercice.\par
Il fallait donc lire le fichier, en tirer les informations essentielles et les réutiliser.
Pour conserver les données contenues dans le fichier j'ai fait appel à un petit enregistrement qui contiendra la configuration de l'utilisateur :
\begin{verbatim}
  Setting = Record
    ResoWidth,ResoHeight : integer;
    Fullscreen,WireFrame : Boolean;
    AAliasing : integer;
    Procedure GetSetting;
  end;
\end{verbatim}
et pour remplir cet enregistrement une petite procédure/boucle de lecture du fichier:
\begin{verbatim}
  AssignFile(MyFile,'config.ini');
  Reset(MyFile);
\end{verbatim}
Ces instructions ouvrent et mettent le curseur de lecture au debut du fichier.
on lance ensuite une boucle de lecture jusqu'a la fin du fichier, cette boucle analyse chacune des phrases du fichier et agit en conséquence :
\begin{verbatim}
  while not(EOF(Myfile)) do
  begin
    Readln(Myfile,MyString);
    if Mystring = '[Resolution]' then
    begin
      Readln(Myfile,MyString);
			[.Traitement de la ligne.]   
		end;
    if Mystring = '[FullScreen]' then
    begin
      Readln(Myfile,MyString);
			[.Traitement de la ligne.]
    end;
    if Mystring = '[WireFrame]' then
    begin
      Readln(Myfile,MyString);
			[.Traitement de la ligne.]
    end;
    if Mystring = '[AntiAliasing]' then
    begin
    	[.Traitement de la ligne.]
    end;
  end;
\end{verbatim}
C'est dans ces moments que l'on regrette le \emph{pattern matching} si élégant du Caml.\par 
\`A l'issue de cette boucle notre enregistrement est rempli par les valeurs adequates, celles--ci seront ré--utilisées dans la création de notre \emph{engine}:
\begin{verbatim}
  if myGame.MySetting.AAliasing=2  then
    Presentpara[0].MultiSample:= MultiSampleType.TwoSamples
    else if myGame.MySetting.AAliasing=4 then
      Presentpara[0].MultiSample:=MultiSampleType.FourSamples
      else if myGame.MySetting.AAliasing=6 then
        Presentpara[0].MultiSample:=MultiSampleType.SixSamples;
\end{verbatim}
Voilà l'exemple de réglage de l'AntiAliasing en fonction de notre enregistrement.
\newpage
\subsection{La Skybox}
Le retour de la méchante Skybox, après les remarques fort blessantes de nos actionnaires concernant notre chef--d'\oe{}oeuvre conceptuel --- Skybox Sphérique avec Texture en mouvement.
Nous sommes revenus à une skybox cubique qui nous permet d'obtenir une grande taille sans faire les frais d'une grosse perte de performance.
On utilise pour cela un \emph{mesh} sous la forme d'un fichier .x
\begin{verbatim}
 myGame.myData.AddourMesh('Skybox','Skybox2.x',myGame.myEngine._D3DDevice);
\end{verbatim}
Celui--ci est chargé en utilisant une de nos procédures, puis affiché encore une fois en ré--utilisant nos procédures --- c'est là qu'on remercie toute la planification faites au debut du projet !
\begin{verbatim}
 DrawMesh(ourmesh(mygame.mydata.m_HTourMesh['Skybox']),
          myGame.myEngine._D3DDevice,Matrix.get_identity);
\end{verbatim}
Le dernier paramètre \emph{Matrix.getidentity} indique que la \emph{skybox} sera dessinée au centre du monde pour englober tout ses éléments.

\begin{center}
\includegraphics{fumeur.jpg}
\end{center}

\newpage

\section{CAMERA Guillaume}
\subsection{Introduction}
	Pour cette nouvelle soutenance, il fallait donné une réelle dimension de jeu. Se ballader dans une map c'est bien mais cela ne rend pas le jeu très intéressant, il fallait donc implémenter :

- Les tirs.\\

- Et des vilains méchants sur qui tirer !    

\subsection{Ce qui a été fait}
Aux cours de ces dernières semaines du chemin fut accomplit, actuellement il est possible de tirer sur des ennemis et de les éliminer. Pour ma part, je me suis chargé de loader nos ennemis dans un premier temps sous forme de sphere avoir de simple cible à réduire en cendre. -- Mais des cendres, ce sont des particules, non ? Nous y reviendrons donc ! Une fois ce travail accompli, je me suis penché sur les tirs mais le graphisme a proprement parlé, c'est-à-dire où et quand les loader, notre grand physicien -- j'ai nommé -- Kouyou, s'est occupé de le faire bouger et de gérer les collisions avec les ennemis afin de les pulvériser.

\subsubsection{Les targets :}
Commençons par le commencement : Nos targets ! Le but de la manoeuvre étant de charger nos targets à des endroits différents dans les proportions de la map. La première étape étant de charger nos meshs sans pour autant perdre en fps. Directx nous propose déjà différents type de meshes donc j'ai choisis de modeliser nos cibles par des spheres, génial c'est possible. Donc une declaration rapide d'une variable de notre record de rendu :\\

\begin{verbatim}
  DaTarget  = record
    model : Mesh;
  end;
\end{verbatim}

Ensuite definition du type de la target :

\begin{verbatim}
  target = record
    position : vector3;
    direction : vector3;
    radius : real;
    mater : Material;
   end;
\end{verbatim}

Puis on crée une liste qui va nous permettre de stocker toutes les targets présentes sur la map, afin de les gérer correctement -- affichage, destruction, etc\ldots   

\begin{verbatim}
  targetlist = record
     list : array [0..MAXTAR] of target;
     length: integer; // qui sera considerer comme etant le nombre d'élément
\end{verbatim}

Le plus compliqué étant de d'initialiser correctement ces targets, nous laisserons ensuite agir la magie des types abstraits.

\underlinePrincipe d'initialisation :\\
Notre enregistrement comprend donc un vecteur position et direction, un rayon afin de gerer sa taille pour l'instant et pour plus tard les collisions avec les tirs.
Au depart, initialisation du vecteur position en X,Y,Z. Cette initialisation doit se faire dans les proportions de la map, c'est-à-dire que les targets ne doivent pas apparaitre en dehors de la map. Heureusement, l'algorithme de la heightmap nous permet de récupérer la largeur et la longueur de la map. Le centre de la map étant placée au point (0,0,0), on fera donc un random sur la moitié de la longeur soutrait a lui même. On fera de meme pour la coordonnée en y avec la largeur. J'ai laissé la manière de gérer les vecteurs directions au concerné, Kouyou. Pour des raisons pratiques le radius de la boule restera fixe et déclaré par une constante. Pour le rendu, on appliquera une lumière rouge sur notre target. 
Une fois l'initialisation finit on stock notre target dans notre liste. En voici le code :
\begin{verbatim}

procedure addtarget (gabon : device);
  var
    x,y,z : integer;
    tmpradius : real;
    mytar : target;
  begin
    Randomize;
    inittarget(gabon);
    // myGame.myList etant une liste de type targetlist
    while (myGame.myList.length < Maxtar) do 
      begin
        x := random(mygame.mymap.height/2) - random(mygame.mymap.height/2);
        y := random(trunc(mygame.maxH)) + 64;
        z := random(mygame.mymap.width/2) - random(mygame.mymap.width/2);
        tmpradius := 1 ;
        mytar.position := vector3.Create(x,y,z);
        mytar.direction := Vector3.Normalize(Vector3.Create(Random(100)-100, 
        																										Random(100)-100, 
        																										Random(100)-100)) ;
        mytar.radius := tmpradius;
        mytar.mater.ambient := color.red;
        mytar.mater.diffuse := color.red;
        mygame.myList.list[mygame.myList.length] := mytar;
        mygame.myList.length := myGame.myList.length + 1;
      end ;
  end ;
  
\end{verbatim}

En ce qui concerne la procédure d'affichage rien de plus classique, on parcourt notre liste où sont contenue nos target puis a chaque tour de boucle on dessine notre target en n'oubliant pas d'inclure au device les paramètres des matériaux qui vont bien.
Notre mesh spherique sera donc dessiné avec les caractériques attribué aux target dans notre tableau, c'est-à-dire que si la target à l'emplacement à un radius X et bien nous scalerons ce mesh de X, puis une translation en fonction de son vecteur position, comme suit :

\begin{verbatim}
 procedure drawtarget(gabon : device);
  var
    i : integer;
  begin
    gabon.settexture(0, NIL);
    for i := 0 to myGame.myList.length do
      begin
        gabon.Transform.World := Matrix.Translation(myGame.myList.list[i].position.x,
                                                    myGame.myList.list[i].position.Y,
                                                    myGame.myList.list[i].position.Z) ;
        gabon.material := myGame.myTarget.mater;
        myGame.myTarget.model.DrawSubset(0);
      end;
  end;
\end{verbatim}

Nous ne sommes pas arreté là quant au rendu proprement parlé, Massy s'est chargé de remplacer ces boules rouges par de vrais ennemis, et Kouyou des déplacements. En ce qui concerne la destruction de l'ennemi placé en X, on le remplacera donc par l ennemi en dernière position dans le tableau puis nous retrancherons 1 au nombre d'elements dans le tableau -- l'ordre n'intervenant pas dans le dessin des ennemis.
\subsubsection{Les tirs :}

Pour la gestions des tirs nous garderons une structure a peu pres identique aux ennemis. En effet, il me faut créer une sphère d'une certaine taille et recuperer la position de caméra. Puis nous stockerons ces tirs dans un tableau qui pourrait eventuellement representer un chargeur et ainsi créer une contrainte supplémentaire pour le joueur afin d'augmenter l'intêret du jeu. Pour l'instant ce n'est qu'une perspective à envisager mais qui se fera certainement sans trop de problèmes. Mais place a ce qui est déjà réalisé.

\underline{Principe de chargement}:\\
Dans le même esprit donc que celui des ennemis a la seule différence la taille de l'objet et la position doit être tirée de celle du vaisseau. Moins de contraintes pour nous puisque les différentes parties du projet nous permettent de récupèrer les valeurs utiles qui vont bien.\\

definition du type des tirs -- Bullet in English.

\begin{verbatim}
 bullet = record
    Matpos : vector3;
    directon : vector3;
    radius : real;

  end;
  
  DaBullet = record
        model : Mesh;
        tex : texture;
        bulmat : material;
  end;
\end{verbatim}

"bullet" sera simplement le type qui recupera les caracteristique du tirs -- postions, direction, \ldots
"Dabullet" sera le notre rendu en voici les differentes procedures.
En voici le code :\\
\begin{verbatim}
procedure initbullet (gabon : device);
  begin
    mygame.mybullet.model := mesh.Sphere(gabon,sqrt(BULLET_RAD),10,10);
    Mygame.mybullet.bulmat.Ambient := color.get_Transparent;
    Mygame.mybullet.bulmat.Diffuse := color.get_Transparent;
    Mygame.mybullet.tex:=Textureloader.FromFile(gabon,'./texture/bullet.png');
    mygame.mytab.nbelt := MAXBULLET ;
  end ;
\end{verbatim}  

Initialisation des caracteristiques ainsi que l'ajout dans une liste :

\begin{verbatim}
procedure addbullet (gabon : device);
  var
    mybullet : bullet;
  begin
     //////// init bullet///////
     mybullet.directon := (ourmesh(mygame.myData.m_HTourMesh[ship])._direction +
     											 ourmesh(mygame.myData.m_HTourMesh[ship])._cam_dir) ;
     mybullet.matpos   := ourmesh(mygame.myData.m_HTourMesh[ship])._position + 
     											15 * ourmesh(mygame.myData.m_HTourMesh[ship])._cam_dir ; 
     ///// init material/////
     if Environment.TickCount mod 4 = 0  then 
       if (mygame.mytab.nbelt > 0) then
         mygame.mytab.nbelt := mygame.mytab.nbelt - 1
       else
         decalage_bullet ;
     mygame.mytab.tab[mygame.mytab.nbelt] := mybullet ;
  end ;
  \end{verbatim}
Puis pour le dessin il suffit de dessiner notre objet "datarget" avec les caracteritiques initialisé.
Pour gérer le nombre de tirs sans trop perdre en mémoire, nous utiliserons un système de fil, les types abstraits c'est bien !

\subsubsection{Moteur à particules}
Nous ne pouvions pas laisser une fois l'ennemi détruit un simple non-affichage de la bête, coder un moteur à particules semblait être la solution la plus approprié.
\\
Encore une fois nous utiliserons le même principe que pour les targets, certes méthode répétitive mais très efficace et en plus avec un joli rendu.
 Voici la définition de notre type représentant notre particule :
 \begin{verbatim}
  type
  particule = record
    position : vector3;
    direction : vector3;
    partmat : material; // material de la particule
    life : double;
    active : boolean;
    fade : double ; //vitesse de disparition
  end;
 \end{verbatim}

J'éviterais de mettre trop de code pour cette partie, car je pense que le système est maintenant bien expliqué, mais en voici les principes :
Le booléen sert à définir si la particule est encore en vie, grace à cela nous pourrons déterminer si la particule doit être à afficher. La position de la particule sera affectée par la position de l'ennemi détruit et la position sera la meme pour toutes les particules à l'instant de destruction de l'ennemi, la vie est fixe et le champs fade choisit aléatoirement sera la valeur retranchée à life à chaque déplacement. Pour les matériaux, une boule sur deux seras rouge, l'autre sera jaune.
Une fois l'initialisation finie on stocke tout ça dans un tableau puis on dessinera de petits carrés avec les caractérisques de particules. Après chaque dessin de particules, on mets à jours les positions grâce à l'addition du vecteur position et déplacement avec un petit random afin de donner aux particules un orbit spacial.     
 
\newpage
\section{BRUNETTI Pierre}
\subsection{Les médias}
Il n'y a pas eu d'énorme avancée au niveau des médias par rapport à la soutenance précedente : j'ai pu simplement, grâce à un BufferPlayflag de DirectX, jouer un son en boucle, pour l'ambiance. J'ai pu également, grâce à AudioVideoPlayback, jouer une vidéo, en fullscreen ou non. Je me frotte désormais à un souci, que faire en sortant de la lecture de cette vidéo ? Il existe un paramètre de la vidéo, video.Ending, qui est censé recevoir une procedure lui disant que faire une fois la vidéo finie, cependant je n'ai pas encore réussi à le manipuler. Ceci nous permettra, par la suite, d'inclure une vidéo d'introduction, ainsi que de revenir au menu une fois la vidéo de credits terminée; car pour l'instant, nous pouvons lire la vidéo, mais l'application se stoppe à la fin de la vidéo. J'approfondierai la lecture de vidéo pour la dernière soutenance, ceci n'étant qu'un détail "`esthétique"' . 
Quand au son du laser, il remplace le son de laser déjà en cours de lecture; idem pour le son de boost. C'est ce que nous avons trouvé le plus adapté aux tirs de laser. 

\subsection{Le moteur physique}
Ma participation à l'évolution du moteur physique n'a pas été exceptionnelle; je vais cependant vous présenter ce que j'ai codé pour notre pseudo - "`intelligence artificielle"' . Je dis pseudo car il est difficile de coder une réelle intelligence artificielle, nous avons donc - pour l'instant - du pur random. Je me suis basé sur les déplacements de notre vaisseau, c'est-à-dire en utilisant les quaternions - comment faire compliqué quand on peut faire simple - . Mais au lieu de mettre à jour la position du vaisseau en fonction des touches pressées, j'ai simplement mis un random.
\begin{verbatim}
	//notre variable recoit le mesh ennemi :
	mesh := ourmesh(myGame.myData.m_HTourMesh['Ennemi']); 
  randomize;  //DA intelligence artificielle
  right := Vector3.Create(1,0,0) ; // nos trois vecteurs, pour les calculs
  up    := Vector3.Create(0,0,1) ;
  dir   := Vector3.Create(0,1,0) ;
  //toute la puissance de notre intelligence artificielle :
  xrot := randomRange(-10,10) / 1000; 
  yrot := randomRange(-10,10) / 1000;
  zrot := randomRange(-10,10) / 1000;
  
  //mesh.rotation est le quaternion associé au mesh, 
  //on passe donc nos vecteurs dans ce quaternion
  //pour pouvoir travailler dans la base "`vaisseau"', et non dans la base "`monde"'
  right := Vector3.TransformCoordinate(right,Matrix.RotationQuaternion(mesh.rotation)); 
  up := Vector3.TransformCoordinate(up,Matrix.RotationQuaternion(mesh.rotation));
  dir := Vector3.TransformCoordinate(dir,Matrix.RotationQuaternion(mesh.rotation));
  
  //puis on multiplie nos trois quaternions, pour obtenir un uber-quaternion qui contient
  //les valeurs des différentes rotations
  addrot := quaternion.Multiply(Quaternion.RotationAxis(up,yrot),
                                quaternion.RotationAxis(right,xrot));
  addrot := quaternion.Multiply(addrot,quaternion.RotationAxis(dir,zrot));
  
  //Finalement, on multiplie le quaternion de notre mesh par notre uber-quaternion : ce
  //nouveau quaternion engendrera la rotation du mesh
  mesh.rotation := mesh.rotation * addrot;
  
  //maintenant, on calcule un vecteur qui servira pour le déplacement du vaisseau
  addvector := vector3.Create(0,1,0);
  //On le passe dans notre quaternion, toujours pour bosser dans la base "`vaisseau"'
  addvector := vector3.TransformCoordinate(addvector, 
  																				 Matrix.RotationQuaternion(mesh.rotation));
  
  //on le normalize avant de l'additionner, c'est mieux pour les calculs
  addvector.Normalize;
  
  //on met à jour la position du vaisseau avec notre super-vecteur
  mesh._position := mesh.position + addvector * speed;
  
  //et on renvoi enfin la nouvelle matrice de l'ennemi, pour qu'on puisse le tracer !!
  result := Matrix.Scaling(0.2,0.2,0.2) * //faut qu'il soit un peu plus petit, 
                                          //donc on le scale
            Matrix.RotationX(PI / 2) * 
            Matrix.RotationQuaternion(mesh.rotation) * //d'abord la rotation
            Matrix.Translation(mesh.position); //puis la translation
  mesh._matrice := result;
\end{verbatim}
  
C'est à peu près tout ce que j'ai codé pour notre moteur physique, même si au fond ca ne fait pas vraiment parti de ce dernier \ldots Kouyou s'est occupé du reste, collisions, et gestions des tirs sur les ennemis. Nous avons donc pu constater que lorsque Kouyou se met à bosser, ca donne quelque chose de plutôt correct !


\newpage
\subsection{Le menu}
\subsubsection{Le traçage}
Je pensais m'y atteler pour la dernière soutenance. Mais une entitée surpuissante, qu'on nomme parfois curiosité, m'a poussé à me pencher sur la question. Et je m'y suis penché. Bien que son implémentation soit totalement barbare - il y a pour l'instant 900 lignes de code - , le résultat n'en est pas moins spectaculaire; je citerais même John Carmack qui, en passant voir l'évolution de notre projet au détour d'un voyage au Togo, l'a qualifié de "`digne des plus grands jeux actuels"'. 
Vu le nombre de textures à afficher, j'ai preferé les stocker dans un tableau - j'ai pensé à utiliser la table de hash de Massy, mais j'ai opté pour une méthode plus saine et plus barbare, le genre de tableau qui se code au burrin et au couteau à beurre - ; j'ai donc une variable de type sprite, qui recoit lors de son initialisation, un \emph{sprite.Create(Device)} .
Ensuite, avant de tracer, il suffit de dire à DirectX que je veux activer l'alphablending, avec \emph{MySprite_var.&Begin(Spriteflags.AlphaBlend)} , et de terminer ce SpriteFlag par un \emph{MySprite_var.&end} .
Enfin, entre ces deux lignes, on trace les images à l'écran grâce à la fonction suivante :
\begin{verbatim}
mySprite.Draw2D(Texture,  //Une texture, que j'ai donc stockée dans mon tableau de textures
           rectangle.Empty, //Ceci indique qu'il tracera l'intégralité de l'image
           SizeF.Create(sizeX,sizeY), //la taille que prendra le sprite à l'écran
           pointF.Create(traceX,traceY), //l'endroit où on trace l'image (coin haut-gauche)
           color.White.ToArgb); //La couleur d'alpha, la couleur qui sera transparente
\end{verbatim}

J'ai donc tracé toutes mes images grâce à cette fonction, avec \emph{sizeX} et \emph{sizeY} ne dépendant que de la résolution : j'ai donc dû calculer à quel pourcentage de la résolution correspondait la taille de chaque image - c'était long -. Je suis finalement arrivé au bout de mes peines. Mais il fallait maintenant pouvoir naviguer dans le menu, c'est-à-dire montrer à l'utilisateur qu'une ligne est sélectionnée ou non; il fallait aussi permettre la navigation avec la souris, ou avec le clavier. J'ai choisi de faire les deux, parce que j'attache énormement d'importance au bien-être de nos futurs utilisateurs.

\subsubsection{La navigation}
Un autre problème s'est imposé : le \emph{KeyboardState} de DirectX est un booléen indiquant si oui ou non une touche est pressée : le souci, c'est que même si la touche est enfoncée une fraction de seconde, les actions après un \emph{if} se font enormement de fois. Exemple avec le code suivant :
\begin{verbatim}
if (myGame.myInput.KeyboardState[Key.Return]) //si la touche "`Entrée"' est pressée
then i := i + 1;
\end{verbatim}
Avec ce code-ci, même lors d'un appui très bref de la touche Entrée, i va s'incrémenter très rapidement : une variable i = 1,2,3 ou 4 - pour les différentes sections du menu, si i=1 alors c'est "`new game"', si i=2 alors c'est "`options"', etc etc - n'était donc pas envisageable. J'ai donc fait des encadrements pour chaque section : si i est compris entre 1 et 100, alors c'est "`new game"' qui est selectionné, si c'est compris entre 300 et 400, c'est "`quit game"', etc. Grâce à cette variable, je sais donc quelle partie du menu est selectionnée par l'utilisateur. J'ai donc un simple :
\begin{verbatim}
if mygame.myInput.KeyboardState[Key.Up] then //Si touche du haut pressée
    selected := selected - 1
  else
  if myGame.myInput.KeyboardState[Key.Down] then //si touche du bas pressée
    selected := selected + 1;
\end{verbatim}
J'ai ensuite "`bloqué"' la variable selected, lorsqu'elle passe en dessous de 1, lors elle reçoit 1, et lorsqu'elle passe au dessus du nombre de parties à selectionner - multiplié par 100, puisque mon encadrement se fait tous les 100 - , alors elle reçoit cette valeur max.
J'ai utilisé le même procédé pour la selection horizontale, lors du choix du vaisseau par exemple.
Lors de l'affichage des images, si selected est compris entre 1 et 100, alors je trace l'image avec le texte en rouge, sinon je trace celle avec le texte en blanc : cela donne l'impression à l'utilisateur que la partie est "`sélectionnée"'.

Une fois la navigation au clavier entierement fonctionnelle, je me suis dis que ce serait sympa d'avoir également une sélection à la souris.
J'ai donc voulu récuperer la position du curseur windows dans notre fenêtre. Peut être ai-je mal cherché, mais je n'ai pas trouvé les coordonnées de ce curseur en absolue, c'est-à-dire sa position par rapport à la fenêtre - à la différente des coordonnées relatives, qui ne sont que les décalages en pixel par rapport à la position précedente - . Je me suis donc créé un vector2, qui allait contenir les positions de ma souris à MOI.
\begin{verbatim}
cursor.X := cursor.X + mygame.myInput.MouseState.X;
  cursor.Y := cursor.Y +  mygame.myInput.MouseState.Y;
\end{verbatim}
De cette manière, comme je bosse en coordonnées relatives, mes variables s'incrémentent ou se décrementent en fonction du décalage de la souris windows : j'obtiens donc les coordonnées exactes de mon curseur, mais en absolue, donc par rapport à la fenêtre de l'application ! Le bonheur.
J'ai donc pu, grâce à ces coordonnées, afficher MON curseur à la place du curseur un peu moche de notre chèr Windows. Il suffit ensuite de faire disparaitre le curseur windows de notre application - grâce à \emph{ Showcursor(false) } - , et d'afficher mon curseur avec la fonction mysprite.Draw2D vue plus haut, en remplaçant traceX et traceY par cursor.X et cursor.Y.
Et le tour est joué !
Après, comme j'ai les coordonnées de ma souris, si jamais elle est entre telle position et telle position, alors \emph{selected} reçoit telle valeur, et la sélection clavier ou souris est ensuite gerée grâce à cette même variable \emph{selected} .

Il ne me reste plus qu'à tester les différents états de la touche entrée et du bouton gauche de la souris - si \emph{mygame.myInput.MouseState.GetMouseButtons[0] <> 0 } , alors on a cliqué sur la souris - , et j'entre dans les différents sous-menus.

En définitive, le menu, c'est que du bonheur, et gratuit en plus, alors pourquoi s'en priver ? 

\newpage
\section{KOUYOUMDJIAN Alexandre}
\subsection{Le moteur physique}
Lors de la dernière soutenance, notre vaisseau spatial était capable de se déplacer avec un 
mouvement accéléré, notamment en ce qui concerne les rotations. Malheureusement, il n'y avait
aucun effet de décélération. C'est pourquoi Pierre Mussolini s'est penché sur le problème, 
qu'il a brillamment résolu.
\par Nos mouvements fonctionnant parfaitement, c'est tout naturellement que nous décidâmes de faire
de notre projet un véritable jeu. Or, nous avons opté pour une sorte de
 \emph{Shoot'em Up}, mais pour \emph{shooter them} il faut des \emph{them}, des ennemis, quoi. 
Bah oui parce que sinon, forcément, ça fait un \emph{shoot nobody up}, et c'est quand même
beaucoup moins marrant ; d'où les ennemis, donc.
\par D'accord, mais quoi comme ennemis ? Des mines volantes, ça peut être pas mal. On s'est
donc attelés à la dure tâche de charger 80 mines à une position aléatoire, et que l'on peut détruire 
à l'aide de nos
quatre canons. Ceux--ci tirent chacun un projectile, donc on a un tir convergent vers une 
certaine direction, laquelle est indiquée par un viseur. Une fois tiré, le projectile continue
à avancer dans sa direction initiale, et s'il rencontre un ennemi, celui--ci explose dans une
mangnifique gerbe de particules \emph{Powered by} Guillaume.
\par Comment ça marche ? Tout d'abord, il faut que le premier projectile tiré soit le premier
à être détruit, car trop vieux donc déjà bien trop loin pour présenter un quelconque intérêt.
Le choix d'une file s'est donc imposé tout naturellement. Pour avoir quelque chose d'aussi
optimisé que possible, la file est statique et circulaire. Ensuite, on vérifie s'il y a 
collision entre chaque projectile et chaque mine. C'est assez lourd, donc on ne le fait que 
si l'altitude du projectile est proche de celle de la mine, et si le projectile n'est pas trop
``vieux''. En effet, à partir d'un certain ``âge'' en secondes, le projectile ne peut
mathématiquement plus être dans la skybox, il est donc inutile de vérifier les collisions, ni
même de le faire avancer.
\par D'ailleurs à propos de collisions, au--lieu de comparer la distance entre le projectile
et la mine avec la somme de leurs rayons, on compare le carré de cette distance avec le carré
de la somme des rayons. Cela permet d'éviter de coûteux et inutiles calculs de racines carrés.
\par En ce qui concerne les collisions avec la \emph{map}, c'est plus simple dans la théorie : 
le rouquin du groupe, Guillaume, stocke la hauteur de chaque sommet de la \emph{map} en fonction de 
son abscisse et de son ordonnée. Dès lors, il devient assez simple de gérer la collision du 
vaisseau par rapport au sommet qui se situe à son aplomb. Malheureusement, il y a quelques 
soucis liés entre autres au fait que les indices du tableaux sont strictements positifs, au
contraire des coordonnées du vaisseau, et aussi à diverses translations et homothéties.
\par En revanche, notre vaisseau, de même que les mines volantes sont soumis aux collisions
avec les parois de la skybox, et entre eux. Ainsi, une collision du vaisseau avec une mine fera
exploser la mine et causera 10\% de dommages structurels.
\par En outre, les mines se déplacent automatiquement selon un algorithme aléatoire assez
simple. Au lancement du jeu, elles se voient attribuer un vecteur direction aléatoire qu'elles
suivent pendant un certain temps, jusqu'à l'application d'une rotation aléatoire à ce vecteur ;
et ainsi de suite.
Ainsi, elles suivent un mouvement naturel, et changeant de temps en temps de direction, comme
on peut s'y attendre de la part de drones automatisés mais peu évolués.
\par En somme, il ne nous manque que des collisions avec le terrain et éventuellement quelques
\emph{features} auxquelles nous n'avons pas encore songé, et nous auront un moteur physique
complet et parfaitement fonctionnel.

\newpage
\section{Conclusion}
En conclusion de ce 3e rapport à nos actionnaires, nous pouvons affirmer les choses suivantes :
\begin{itemize}
\item Un menu avec des sprites, c'est beau
\item Debugger prend enormement de temps, puisque il faut minimum 3 min pour s'arrêter de tirer sur les ennemis
\item Les Fatal Picard représentent l'avenir de la musique contemporaine
\item Il paraitrait que le monde ait été codé en DirectX ...
\item MegaZorg est vraiment un loser (un peu comme Kouyou, si on réflechit bien ...)
\item C'est tellement jouissif de créer un jeu qu'on en dort plus la nuit
\item C'est toujours aussi pratique de dormir chez Moumoutte ...
\item Quand Kouyou se met à bosser, ça soulage !
\item MSN Messenger est le fléau de l'humanité
\item C'est quand même plus rigolo de coder que de tapper un rapport de soutenance
\item Trouver une conclusion digne de ce nom, c'est pas si facile
\item Vous avez entendu parler de DirectX ? Parait-il qu'on l'aurait utilisé pour ...
\item J'ai bien peur que ce soit la dernière affirmation de ce rapport de 3e soutenance
\end{itemize}
\par
Et c'est avec joie que nous nous retrouverons pour la dernière soutenance, et en english, s'il vous please !
\begin{center}
\includegraphics{scan3-2.jpg}
\end{center}
\end{document}